Microcircuit devices are used in a variety of products, from automobiles to microwaves to personal computers. Designing and fabricating microcircuit devices involves many steps; which has become known as a ‘design flow,’ the particular steps of which are highly dependent on the type of microcircuit, the complexity, the design team, and the microcircuit fabricator or foundry. Several steps are common to all design flows: first a design specification is modeled logically, typically in a hardware design language (HDL). Software and hardware “tools” verify the design at various stages of the design flow by running software simulators and/or hardware emulators, and errors are corrected.
More particularly, after the logical design is deemed satisfactory, it is converted into physical design data by synthesis software. The physical design data may represent, for example, the pattern that will be written onto a mask used to fabricate the desired microcircuit device in a photolithographic process at a foundry. It is very important that the physical design information accurately embody the design specification and logical design for proper operation of the device. Further, because the physical design data is employed to create masks used at a foundry, the data must conform to foundry requirements. Each foundry specifies its own physical design parameters for compliance with their process, equipment, and techniques.
First generation emulation systems were formed using general purpose reconfigurable electronic structures formed in an integrated circuit (IC). These reconfigurable electronic structures might include, for example, reconfigurable logic elements, such as general purpose field programmable gate arrays (FPGAs), and reconfigurable interconnects, such as crossbars. To emulate a circuit design on this type of emulation system, the circuit design would be “realized” by first compiling a formal description of the circuit design (expressed, for example, in a hardware description language such as Verilog). The circuit design then would be partitioned into subsets of related components (also referred to as netlists). The various netlists next would be mapped to the logic elements of the field programmable gate arrays of the emulation system, while the reconfigurable interconnects would be configured to interconnect the logic elements. The partitioning and mapping operations typically would be performed on workstations that were part of (or complementary to) the emulation system. Finally, the resultant configuration information (that is, the information to configure the reconfigurable logic elements and/or interconnects) would be downloaded to the logic boards hosting the integrated circuits with the reconfigurable electronic structures, and then to the reconfigurable structures themselves. With advances in integrated circuit and emulation technology, more recent model emulation systems may employ FPGAs specifically designed for emulation purposes. These special FPGAs typically will include a substantial number of on-chip reconfigurable logic elements, interconnects, memory, and debugging resources.
During the emulation process, test stimuli normally are generated either by the workstation or by a service board of the emulation system under the control of the workstation. The test stimuli is then transferred to the various logic boards as input into the reconfigurable logic integrated circuits for application to the various netlists of the circuit design being emulated. To emulate the operation of the circuit design, emulation signals often need to be transferred from one reconfigurable logic integrated circuit to another. At appropriate points in time, the state data of various circuit elements and/or various signals (sometimes referred to as “traces”) of interest for the circuit design are read out of the appropriate reconfigurable logic integrated circuits and then transferred to the companion workstation for analysis.
Some conventional emulation systems obtain the state values of a circuit design for each clock cycle of the emulation process. Depending upon the number of state values being sampled from the emulated circuit, however, the obtained data might be too much information for the emulation system to process on a timely or useful basis. Accordingly, some emulation systems will only capture the state values at intervals, rather than at every clock cycle. The emulation system will then calculate the unsampled state values for every cycle, based upon the sampled state values and the combinational logic embodied by the circuit design.
This interval sampling technique provides some advantages over physically obtaining every state value at each emulated clock cycle. Depending upon the size of the circuit design, however, even this technique often is still too slow and processing intensive to be useful for analyzing the operation of the emulated circuit. Some emulation systems attempt to address this problem by using one or more alternate processing resources to assist in calculating the unsampled state values. For example, if the emulation system is being used in conjunction with a software-implemented simulation system, then some emulation systems will use the software simulator to calculate the unsampled state values. Even with the use of alternate processing resources, however, many circuit designs are still too large and complex for their state element values to be practically calculated at each emulated clock cycle.